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Abstract 


This paper investigates a critical access control issue in the Internet of Things (IoT). In particular, we propose 
a smart contract-based framework, which consists of multiple access control contracts (ACCs), one judge con- 
tract (JC) and one register contract (RC), to achieve distributed and trustworthy access control for IoT sys- 
tems. Each ACC provides one access control method for a subject-object pair, and implements both static ac- 
cess right validation based on predefined policies and dynamic access right validation by checking the be- 
havior of the subject. The JC implements a misbehavior-judging method to facilitate the dynamic validation 
of the ACCs by receiving misbehavior reports from the ACCs, judging the misbehavior and returning the cor- 
responding penalty. The RC registers the information of the access control and misbehavior-judging methods 
as well as their smart contracts, and also provides functions (e.g., register, update and delete) to manage 
these methods. To demonstrate the application of the framework, we provide a case study in an IoT system 
with one desktop computer, one laptop and two Raspberry Pi single-board computers, where the ACCs, JC 
and RC are implemented based on the Ethereum smart contract platform to achieve the access control. 


Index Terms: Internet of Things, access control, blockchain, smart contract. 


I INTRODUCTION 


Thanks to the rapid advance of communication and networking technologies (e.g., Wi-Fi, Zigbee, Bluetooth), 
a growing number of objects (e.g., sensors, actuators, smart devices) are being connected to the Internet 
nowadays, leading to the concept of the Internet of things (IoT) [1, 2]. The ubiquitous interconnection of 
physical objects significantly accelerates data collection, aggregation and sharing in the IoT, making the IoT 
one of the most fundamental architectures for various promising applications such as smart healthcare, in- 
telligent transportation, home automation, etc. [3, 4]. However, such interconnection may also incur crucial 
security issues into IoT systems, because adversaries can intrude into the systems to gain illegal access to the 
provided resources (e.g., data, services, storage units, computing units) by simply deploying their own or 
compromising existing IoT devices [5, 6]. Thus, access control, which aims to prevent the illegal resource ac- 
cess from unauthorized entities, has been regarded as an increasingly vital research issue in the IoT for both 
academia and industry [7, 8, 9]. 


Traditional IoT access control schemes are mainly built on top of the well-known access control models in- 
cluding the role-based access control model (RBAC) [10], the attributed-based access control model (ABAC) [ 
11] and the capability-based access control model (CapBAC) [12]. In the RBAC-based schemes, the access con- 
trol is based on the roles (e.g., administer, guest) of subjects Ge. entities that access resources) within an or- 
ganization. By associating the roles with access rights (e.g., read, write, execute) and assigning the roles to the 
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subjects, the RBAC-based schemes can establish a many-to-many relationship between the access rights and 
the subjects [13, 14]. The ABAC-based schemes implement the access control based on policies, which com- 
bine various types of attributes, such as subject attributes, object (i.e., the entity that holds resources) at- 
tributes and environment attributes, etc., to define a set of rules expressing under what conditions access 
rights can be granted to subjects [15, 16]. In the CapBAC-based schemes, access rights are granted to subjects 
based on the concept of capability, which is a transferable and unforgeable token of authority (e.g, a key, a 
ticket), and describes a set of access rights for each subject [17, 18]. 


It is notable that, in the above schemes, validating the access rights of subjects is usually conducted by a cen- 
tralized entity, which turns out to be a single point of failure. To address this issue, distributed CapBAC mod- 
els have been proposed recently [19, 20], where the access right validation is performed by the requested IoT 
objects themselves rather than a centralized entity. However, IoT objects are usually with low capability and 
thus may be easily compromised by adversaries, so they cannot be fully trusted as the access right validation 
entities. As a result, the distributed CapBAC models may fail to tackle the access control problem in untrust- 
worthy IoT environments. Thus, a crucial question arises: how can we achieve distributed and trustworthy 
access control in the IoT? The answer may lie in the emerging blockchain technology, the key enabler behind 
modern cryptocurrency systems like the Bitcoin [21] and Ethereum [22]. The blockchain is initially created 
as a distributed and immutable ledger of transactions for cryptocurrency systems. Thanks to the invention of 
smart contracts (executable codes that reside in the blockchain), the blockchain has now evolved into a 
promising platform for developing distributed and trustworthy applications, and has attracted considerable 
attentions from researchers in the IoT community [23, 24]. Therefore, this paper aims to apply the smart 
contract-enabled blockchain technology to achieve distributed and trustworthy access control for the IoT. 


Some initial work has been done on the blockchain-based access control. The authors in [25] considered the 
access control issue in an IoT network with service providers, cloud storage, user devices and smart homes, 
each containing a miner and multiple IoT devices. Each home miner maintains a local private blockchain 
with a policy header storing access control policies to control all the access requests related to the home, i.e., 
internal, incoming and outgoing requests. However, the authors eliminated the critical proof-of-work 
process [26] in the blockchain technology, resulting in an untrustworthy access control scheme. Notice that 
the main purpose of the blockchain in [25] is to serve as a distributed and immutable storage for access con- 
trol policies, whereas the computing capability of the blockchain was largely wasted. The idea of using the 
blockchain to only store access control policies has also been adopted in [27, 28]. Recently, the computing ca- 
pability of the blockchain has been exploited in [29] for access control, where the blockchain plays the role 
of a decentralized access control manager. The authors used access tokens to represent access rights and the 
tokens can be delivered from one peer to another through transactions. When delivering a token, the sender 
embeds access control policies into the locking scripts of the transaction output. The receiver of the token 
must unlock the locking scripts to prove the possession of the token (i.e., the access rights to a certain re- 
source). Using this scheme, a peer can be granted access rights by receiving a token, grant access rights to an- 
other subject by delivering a token, and access an object by spending a token. Although using locking scripts 
for access control is an excellent idea, the computing capability of locking scripts is significantly limited. 
Different from [29], this paper utilizes smart contracts to provide a much higher computing capability for 
achieving various access control methods. Notice that the idea of using smart contracts for access control has 
been adopted in [30, 31], where, different from this paper, the main purpose of the smart contracts is to 
manage data records. 


To address the limitations of the above works, this paper proposes a smart contract-based access control 
framework, which consists of multiple access control contracts (ACCs), one judge contract (JC) and one regis- 
ter contract (RC), to achieve distributed and trustworthy access control for IoT systems. In the framework, 
each ACC provides one access control method for a subject-object pair, which implements both static access 
right validation based on predefined access control policies and dynamic access right validation by checking 
the behavior of the subject. The ACCs also provide functions for adding, updating and deleting access control 
policies. Once called by a subject for access control, the ACC will be run and verified by most participants in 
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the system, ensuring the trustworthiness of the access control. To facilitate the dynamic validation of the 
ACCs, the JC provides a misbehavior-judging method, which receives misbehavior reports about the subjects 
from the ACCs, judges the misbehavior and returns the corresponding penalty. To manage the access control 
and misbehavior-judging methods, the RC registers the information (e.g., name, subject, object, smart con- 
tract) of the methods and also provides functions to register a new method and update or delete an existing 
method. To demonstrate the application of the framework, we provide a case study, in which we employ the 
Ethereum smart contract platform to implement the ACCs, JC and RC for the access control in a IoT system 
with one desktop computer, one laptop and two Raspberry Pi single-board computers. 


The remainder of this paper is organized as follows. Section II presents the IoT system considered in this pa- 
per and Section III introduces the underlying smart contract platform for our access control framework. We 
introduce the distributed smart contract-based framework in Section IV and provide a case study for the pro- 


posed framework in Section V. Finally, Section VI concludes this paper. 


II SYSTEM ARCHITECTURE 
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Figure 1: Illustration of the considered IoT system. 


As illustrated in Fig. 1, the IoT system considered in this paper consists of a large number of servers, storage 
devices, IoT gateways and user devices, which are connected together through a peer-to-peer (P2P) network. 
Also present in the system are numerous IoT devices (e.g., sensors and actuators), which are connected to the 
P2P network via the IoT gateways. The main roles of the peers are explained as follows. 


e Server: A server is a device or a cluster of devices that can interact with the IoT devices and storage de- 
vices to provide a variety of services (e.g., smart home) for users. Interactions between the servers and 
other peers (e.g., IoT devices, storage devices) include collecting environmental data from the sensors, 
sending commands to the actuators to perform some operation, querying data from or storing data to 


the storage devices, etc. 
e Storage device: A storage device can store data for other peers of the system, like the servers, sensors and 
users. Various data can be stored on the storage devices, like the application data of the servers, envi- 


https://ardiv.labs.arxiv.org/html/1802.04410 3/24 


11/7/23, 10:01 AM [1802.04410] Smart Contract-Based Access Control for the Internet of Things 


ronmental data gathered by the sensors, user profiles, etc. 


e User device: A user device is a device (e.g., PCs, laptops, smart phones) through which users can enjoy the 
services (e.g., checking the current temperature of his/her own house) provided by the servers and read 
data from or write data to the storage devices. 


e IoT gateway: Each IoT gateway connects a cluster of IoT devices to the P2P network via short-range com- 
munication technologies like Bluetooth, Wi-Fi and Zigbee, and serves as the service agent for these IoT 
devices at the same time. 


e IoT device: The IoT devices in the system mainly include sensors, which can perceive environmental data 
(e.g., temperature) and send these data to the servers or storage devices for further use, and actuators, 
which can perform some operations (e.g., turning on the air conditioner) once receiving a command 
from users. 


In typical IoT applications, each peer may have some resources (e.g., services, data, storage space) that are 
needed by the other peers. Thus, access control must be implemented by all resource owners to prevent 
unauthorized use of their resources. For example, a server must be able to block the access requests from 
users who has not signed up, or the access requests from signed-up users for some services that they have 
not subscribed. To prevent illegal use of its storage space and data, a storage device must be able to restrict 
the access requests from unauthorized peers for querying data or storing data. An IoT device must be able to 
deny the unauthorized access requests for retrieving its data or controlling its actuators. 


The aim of this paper is to address the critical access control issue for the above IoT system. In particular, we 


will propose an access control framework based on smart contracts to implement distributed and trustwor- 
thy access control. 


III Smart CONTRACT PLATFORM 


III-A Ethereum Platform 


The proposed framework is based on the Ethereum smart contract platform [22], through which each peer of 
the system can implement access control for its resources. The main elements of the Ethereum platform are 
briefly introduced as follows. For a detailed introduction to the Ethereum platform, please refer to [32]. 
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Figure 2: Illustration of a blockchain. 
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e Account/Address: Ethereum has two types of accounts: externally controlled accounts and contract ac- 
counts, both identified by a 20-byte address. We refer to the former simply as accounts and the latter as 
smart contracts or contracts throughout this paper. 


e Smart contract: A smart contract or contract is regarded as a special account that has associated code (i.e., 
its functions) and data (i.e., its state) [33]. In general, a smart contract is compiled into a piece of byte- 
code in an Ethereum-specific binary format (i.e., Ethereum Virtual Machine bytecode) and deployed by 
an account to a global database known as blockchain. A smart contract usually provides many func- 
tions or application binary interfaces (ABIs) that can be used to interact with it. These ABIs can be exe- 
cuted by sending a transaction from an account or a message from another contract. They can also be 
executed by simply invoking the call function without sending transactions and messages. Notice that 
only the former approach can modify the data (or state) of the contract. 


e Transaction and Message: A transaction is a data package signed and sent by an account to transfer some 
ether (Ethereum’s native token) to another account. In addition to transferring ether, a transaction can 
also be sent with some parameters to execute the ABIs of a contract. A message is like a transaction, but 
it is sent by a contract instead of an account to run the associated ABIs of another contract. 


e Blockchain: Like most platforms such as Bitcoin, Ethereum also has a blockchain, which contains blocks 
of transactions and smart contracts with each block containing the hash of its previous block, as illus- 
trated in Fig. 2. Every node connected to the network may have a local copy of the blockchain, and help 


maintain and update the blockchain by including new blocks. 


e Mining: Mining is a process that includes new blocks of transactions and contracts into the blockchain. 
The nodes performing this task are called miners. In one mining around, each miner constructs a block 
of newly generated transactions and contracts, and executes the proof-of-work consensus algorithm, 
where the miners repeatedly guesses random numbers to solve an extremely difficult cryptographic 
puzzle problem related to its block until one of them wins. The winning miner then broadcasts its block 
to the other nodes in the network to validate the block. For the block validation, each node not only 
checks the formats of the transactions and contracts in the block, but also executes the ABIs called by 
these transactions in its local EVM. If the formats of the transactions and contracts as well as the results 
of the called ABIs are valid, the other nodes will include the new block into its local blockchain; other- 
wise, they will discard the block. Through mining, the whole system reaches a common tamper-resis- 
tant consensus on the blockchain and no participant can deceive the others by wrongly executing the 
ABIs, as long as it controls no more than half of the computing power of the system. This is the key to 
achieving trustworthy access control for IoT systems. Notice that the mining in current implementation 
of the Ethereum is based on the concept of proof-of-work, while a novel proof-of-stake consensus algo- 
rithm [34], which depends on the economic stake of miners instead of their computing computing 
power, will be used in future implementation of Ethereum. 


III-B System Configurations 


To apply the Ethereum platform in our access control framework, we need to make the following basic con- 
figurations to the system. 


e Each peer must be associated with an Ethereum account to represent itself in the system. Using the ac- 
count, each peer can claim the deployment of a smart contract and identify itself during the access 
control. 


¢ The Ethereum client can be run at all peers in the system except for IoT devices, due to the limited energy 
and computing power of IoT devices. All clients are assumed synchronized on the same block. Using the 
client, each peer except for IoT devices can directly interact with the blockchain to deploy smart con- 
tracts and send transactions to run the ABIs of smart contracts. These peers can also function as miners 
to conduct the mining task for the system. 
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e As IoT devices has no Ethereum clients, the IoT gateways act as agents for their local IoT devices to con- 
duct access control for the resources of the IoT devices. To achieve this goal, each gateway stores the ac- 
counts of its local IoT devices and uses these accounts to sign transactions for deploying and running 
smart contracts on behalf of its local IoT devices. We assume gateways are physically accessible and 
thus unlikely to be compromised, so they can be trusted as the agents. 


IV Access CONTROL FRAMEWORK 


This section presents the smart contract-based distributed access control framework. We first introduce the 
system of smart contracts in the framework and then explain the main functions provided by the 


framework. 
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Figure 3: Illustration of smart contract system. 


IV-A Smart Contract System 


As illustrated in Fig. 3, the proposed framework consists of multiple access control contracts (ACCs), each of 
which implements the access control for a pair of peers, one judge contract (JC), which receives the misbe- 
havior report of a peer from an ACC, judges the misbehavior and determines the corresponding penalty, and 
one register contract (RC), which stores the information of the JC and ACCs and provide functions to manage 


these contracts. Each of the contracts is introduced as follows. 


IV-A1 Access control contract (ACC) 


An ACC (e.g., ACC 1, ACC 2, ACC 3 in Fig. 3) is deployed by a peer (object) who wants to control the access re- 


quests from another peer (subject). We assume that the subject-object pair can agree on multiple access con- 
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trol methods, and each method is implemented by one ACC. As a result, one subject-object pair can be associ- 
ated with multiple ACCs, but one ACC can be associated with one and only one subject-object pair. In this 
framework, to control the access requests from the subject, each ACC implements not only static access right 
validation by checking predefined policies but also dynamic validation by checking the behavior of the 
subject. 


TABLE I: Illustration of policy list. 


Resource | Action | Permission | ToLR 

2017-12-11 16:19 
2017-12-12 20:34 
deny 2017-12-11 16:19 


file A 
Program A 


write 


execute 


An example of the ACC is given as follows. In this example, to achieve the access control, the ACC maintains a 
policy list as illustrated in Table I, in which each row corresponds to the policy defined on a certain (re- 
source, action) pair. The basic fields of each row are: 


e Resource: the resource for which the policy is defined, such as a file, a computing unit and a storage unit, 
etc.; 


e Action: the action that is performed on the resource, such as read, write, execute, etc.; 
e Permission: the static permission predefined on the action, such as allow, deny, etc.; and 
e Time of last request (ToLR): the time of the last access request from the subject. 


The Permission field can be used for static validation and the ToLR can be used for dynamic validation, such 
as detecting the misbehavior that the subject sends access requests too frequently in a short period of time. 


To record the misbehavior that the subject has exhibited on a certain resource as well as the corresponding 
penalty, the ACC also maintains a misbehavior list for each resource (as illustrated in Table ID, where each 
row has the following basic fields: 


e Misbehavior: the misbehavior of the subject on this resource, such as too frequent request in a short pe- 
riod of time, etc.; 


e Time: the time when the misbehavior is exhibited; and 


e Penalty: the penalty on the subject for its misbehavior, such as blocking its access requests for a certain pe- 
riod of time, etc.; 


The Misbehavior field may also describe the details of the misbehavior to facilitate the misbehavior judging 
at the JC. 


TABLE II: Illustration of misbehavior list for each resource. 


Misbehavior Time Penalty 
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Too frequent access | 2017-12-11 16:19 | blocked for 2 hours 
Too frequent access | 2017-12-12 20:34 | blocked for 4 hours 


The ACC also provides the following main ABIs to manage the policies and implement the access control. 


e policyAddQ: This ABI receives the information of a new access control policy and adds the information to 
the policy list. 


e policyUpdate(: This ABI receives the information of a policy that needs to be updated and updates the 
policy. 


e policyDelete(: This ABI receives the identification information of a policy and deletes the policy. 


e accessControl(: This ABI receives the information required for access control and returns the access result 
and penalty. This ABI implements both the static and dynamic validation. When the subject calls (by 
sending a transaction) this ABI to authorize its current access request, both the static and dynamic vali- 
dation processes will start to check the validity of the request. Once a possible misbehavior is detected, 
the ACC reports it to the JC by sending a message to execute the misbehaviorJudge ABI of the JC, receives 
a penalty decision on the misbehavior from the JC and takes countermeasures based on the penalty de- 
cision. The access request is authorized if and only if it successfully passes both the static and dynamic 
validation processes. 


e setjCQ: In order for the ACC to execute the ABI of the JC, the ACC needs to keep an instance of the JC, so this 
ABI is to receive the address of the JC and set the JC instance. 


e deleteACCQ: This ABI performs the selfdestruct operation to remove the code and storage of the ACC from 
the blockchain [33], such that the ACC can no longer be available. 


Notice that only the creator of the ACC can add a new policy, update or delete an existing policy, set the JC 
and delete the ACC. Thus, permission must be carefully considered in the implementation of the ABIs. 


IV-A2 Judge contract (JC) 


The JC implements a misbehavior-judging method, which judges the misbehavior of the subject and deter- 
mines the corresponding penalty, when receiving a potential misbehavior report from an ACC, as illustrated 
in Fig. 3. The penalty can be based on the misbehavior history of the subject, so the JC may need to keep a 
record of the misbehavior history of all subjects. After determining the penalty, the JC returns the decision to 
the ACC for further operation. Here, we give an example of the JC, which maintains a misbehavior list for 


each subject who has behaved abnormally, as illustrated in Fig. 4. The fields of each record include: 
e Object: the peer who suffered from the misbehavior; 
e Misbehavior: the details of the misbehavior; 


e Time: the time when the misbehavior is exhibited; and 


e Penalty: the penalty imposed on the misbehavior. 
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Figure 4: Illustration of misbehavior records. 


The JC also provides the following main ABIs for judging misbehavior, determining the penalty and manag- 
ing the JC. 


e misbehaviorJudge(: This ABI can be run by any ACC to report the misbehavior of a subject to the JC. After 
receiving the report, this ABI judges the misbehavior of the subject, determines the penalty on the sub- 
ject based on the misbehavior history of the subject and returns the penalty decision to the ACC that re- 
ported the misbehavior. This ABI also adds a new misbehavior record to the misbehavior list of the 
subject. 


e deleteJCQ: This ABI performs the selfdestruct operation to delete the JC. 


IV-A3 Register contract (RC) 


The main role of the RC in the system is to manage the access control and misbehavior-judging methods. To 
achieve this goal, the RC maintains a lookup table, which registers the required information to find and exe- 
cute all the methods. An example of the lookup table is given in Table III, in which each row contains the fol- 
lowing information of a method: 


e MethodName: the name of the method; 

e Subject: the subject of the corresponding subject-object pair of the method; 

e Object: the object of the corresponding subject-object pair of the method; 

e ScName: the name of the corresponding smart contract implementing this method; 
e Creator: the peer who created and deployed the contract; 

e ScAddress: the address of the smart contract; and 

e ABI: the ABIs provided by the contract. 


For the JC, the Subject and Object fields are left blank. In general, the object is the creator of the ACC as well 
as the creator of the access control method. Notice that for the case where the object is an IoT device, the cre- 
ator is the local gateway, i.e., the agent for deploying contracts and sending transactions for the IoT device. 
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TABLE III: Illustration of lookup table. 


MethodName | Subject | Object Creator | ScAddress ABI 
Method 1 Server A aged Sensor B_ | 0xca35b7d915458ef540ade6068dfe2f44e8fa733c | accessControl(),. 
Method 2 Server A a ACC2 | Sensor B_ | 0xab072c469475346532bf47aea86df61 761049565 | accessControl(),. 


Method 3 Sensor B rae ACC 3 Server A | Oxb51f6d86d4c99853 1056a501344060fbafc32a48 | accessControl(),. 


JC 0x3£23c7b929cced4 19 1ef6064ficb33902ea1d92b | misbehaviorJudg 


With the help of the lookup table, the RC provides the following main ABIs to mange these methods. 


e methodRegister(: This ABI receives the information of a new method and registers the information into 
the lookup table. 


e methodUpdate(: This ABI receives the information of an existing method that needs to be updated and up- 
date the information, especially the fields of ScAddress and ABI. 


e methodDelete(): This ABI receives the MethodName of a method and deletes the method from the lookup 
table. 


e getContract(): This ABI receives the MethodName of a method and returns the address and ABIs of the con- 
tract (i.e., the ACCs and JC) of the method. 


Notice that only the creator of the method can register, update and delete the method. 


IV-B Main Functions of the Framework 


With the help of the ACC, JC and RC smart contracts, the framework can provide many functions to facilitate 
the access control of the IoT system. These functions mainly include registering, updating and deleting an ac- 
cess control method; registering and updating the misbehavior-judging method; adding, updating and delet- 
ing a policy of an ACC; and the access control for a subject-object pair. The process of each function is ex- 
plained as follows. 


IV-B1 Registering a new access control method 


A subject-object pair can agree on a new access control method, which is registered by the creator (i.e., the 
object) of the method through the following steps. 


e Step 1: Create (i.e., write and compile) an ACC for the new method. 
e Step 2: Send a transaction to deploy the newly created ACC onto the blockchain. 


e Step 3: Send a transaction to call the methodRegister ABI of the RC to register the required information of 
the new ACC in the lookup table of the RC. 


Registering the misbehavior-juding method follows the same steps as above. 


IV-B2 Updating an existing access control method 


A subject-object pair can agree on updating an existing access control method, which is conducted by the cre- 
ator of the method through the following steps. 
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e Step 1: Create a new ACC, which is used to replace the old one. 
e Step 2: Send a transaction to deploy the newly created ACC onto the blockchain. 


e Step 3: Send a transaction to run the methodUpdate ABI of the RC to update the ACC-related fields of the 
method, such as the ScName, ScAddress, ABI, etc.. 


e Step 4: Send a transaction to run the deleteACC ABI of the old ACC to destruct it. 


Updating the misbehavior-juding method follows the same steps as above. 


IV-B3 Deleting an existing access control method 


A subject-object pair can agree on deleting an existing access control method, which is conducted by the cre- 
ator of the method through the following steps. 


e Step 1: Send a transaction to run the methodDelete ABI of the RC to delete the information of the existing 
method from the lookup table. 


e Step 2: Send a transaction to run the deleteACC ABI of the ACC of the method. 


IV-B4 Adding, updating and deleting a policy 


A subject-object can agree on adding an access control policy for a newly-deployed resource, which is con- 
ducted by the creator of the method through sending a transaction to call the policyAdd ABI of the corre- 
sponding ACC. Similarly, the creator can send a transaction to call the policyUpdate (resp. policyDelete) ABI of 
the ACC to update (resp. delete) an existing policy of the access control method. 


IV-B5 Access control 


The ACC for the access control between a subject-object pair can be called by either the subject or the object. 
We assume that both the subject and object know the names of all the available methods for the access con- 
trol between them. The illustration of the case where the ACC is called by the subject is given in Fig. 5a, 
where a server (the subject) wants to access the resource of an IoT device (the object). To complete the access 
control, the following steps are executed: 


header 


JNSOI SS3998 WINS */ 


2: return the ACC 
(e.g. ACC 2) 


JNSII SSI99V WANA :Q 


x 
i t local interactions 
pes nets gp ZOCLELN n bei e 

[Gateway] Maccsacuscscss wel p | ateway | ~ 7 , 
8: forward access result IoT device 


i Local gat j 
Server Local gateway IoT device Server ee GUENON (Object) 


(Subject) (Object) (Subject) 


(a) ACC called by the subject. (b) ACC called by the object. 
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* Step 1: The server calls the getContract ABI of the RC to retrieve the ACC (e.g., the ACC 2 in Fig. 5a) for the 


access control. 


[1802.04410] Smart Contract-Based Access Control for the Internet of Things 


Figure 5: Illustration of access control. 


e Step 2: The RC returns the address and ABI of the ACC to the server. 


° Step 3: The server sends a transaction, which contains the required information for access control, to call 
the accessControl ABI of the ACC. This transaction will be encapsulated in a new block and the access- 
Control ABI will not be executed until the new block is mined and included in the blockchain by some 


miner. 


e Step 4: During the access control process, the ACC will send a message to call the misbehaviorJudge ABI of 


the JC, if some potential misbehavior of the subject is detected. 


e Step 5: Once the misbehaviorJudge ABI completes juding the misbehavior and determining the penalty, it 


will return the penalty to the ACC. 


e Step 6: Finally, the access result will be returned to both the subject and object, after the access control 
process finishes. 


Since all miners will reach a consensus on the result of the access control through mining, so no miners can 
tamper with the access control process. As the agent of the IoT device, the local gateway informs the IoT de- 
vice the real-time status of the access control, such as the arrival of access requests and the access results, via 
secure local interactions. Fig. 5b illustrates the case where the ACC is called by the object. The main differ- 
ence between the access control in Fig. 5b and that in Fig. 5a is that the access request of the subject (resp. 
the access result) in Fig. 5b is forwarded by the object rather than being directly sent to the accessControl ABI 


of the ACC (resp. the subject). 


TABLE IV: Specifications of devices. 


Device CPU Operating System Memory Hard Disk 
Dell Inspiron 3650 Intel Core 17-6700, 3.40GHz Windows 10 Home (64 bit) | 16GB 2TB 

MacBook Pro Intel Core i5, 2GHz ee WNewlou 8GB 256GB 
Raspberry Pi 3 quad-core ARM Cortex A53, Raspbian GNU/Linux 8 1GB 16GB (microSD 
Model B 1.2GHz (jessie) SDRAM card) 


V Case STUDY 


This section provides a case study to demonstrate the application of the proposed framework for distributed 
access control in the IoT. We first introduce the hardware and software used in the study and then present 
how the access control is implemented based on the framework. Finally, we show some experiment results. 
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Figure 6: Hardware used in the case study. 


V-A Hardware and Software 


We considered a case with one desktop computer (Dell Inspiron 3650), one laptop (MacBook Pro) and two 
single-board computers (Raspberriy Pi 3 Model B), as shown in Fig. 6. The specifications of these devices are 
listed in Table IV. The desktop and laptop correspond to the user devices in the system and the single-board 
computers correspond to the local gateways. We considered the access control issue between the single- 
board computers, of which one serves as the subject (or the agent of the subject) and the other severs as the 


object (or the agent of the object). 


On each device, a geth client [35] (a command line interface implemented in the Go language) was installed 
to transform the device into an Ethereum node. With the geth clients, we created an Ethereum account for 
each node and configured these nodes to form a private blockchain network (as illustrated in Fig. 7), where 
the desktop computer and the laptop play the roles of miners due to their relatively large computing and 
storage capability, and the single-board computers function as lightweight Ethereum nodes that deploy ACCs 


and send transactions for access control. 


For writing and compiling the ACC at the object side, we utilized the Remix integrated development environ- 
ment (IDE) [36], which is a browser-based IDE for Solidity (i.e., the programming language for writing smart 
contracts) [37]. In addition, we adopted the web3.js [38] (i.e., the official Ethereum JavaScript APD at the ob- 
ject side to interact with the corresponding geth client through HTTP connections for deploying the compiled 
ACC and also monitoring the states of the ACC ( i.e., the results of the access control). The web3.js was also in- 
stalled at the subject side to interact with the geth for sending access requests to the ACC via transactions and 
also receiving the access control results from the ACC. 
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Miners 


blockchain 
send access aeri i 
request & get eploy & monitor 
ACCs 
result 


Figure 7: Software used in the case study. 


V-B Implementation 


The implementation of the ACC, RC and JC is based on the examples in Section IV-A. 


V-B1 ACC 


In this implementation, we defined a simple misbehavior, which is sending access requests too frequently in 
a short period of time. To help characterize the misbehavior, we added the following fields to the rows (i.e., 
policies) in Table I: 


¢ mininterval: the minimum allowable time interval between two successive requests. If the time interval 
between two successive requests is less than or equal to minInterval, the later request will be treated as 
a frequent request. 


¢ NoFR: the number of frequent requests in a short time period. 


e threshold: the threshold on the NoFR. If the NoFR is larger than or equal to the threshold, the ACC judges 
that a misbehavior occurs. 


As the penalty for the misbehavior, the access requests from the subject will be blocked for a certain time pe- 
riod. We introduced a variable timeOfUnblock for each resource to represent the time until when requests 
are blocked, which is set to 0 when the requests are unblocked. We used a struct to store the fields of a policy 
and applied a two-dimensional mapping from the fields of resource (primary key) and action (secondary key) 
to this struct to construct the policy list. The ACC also contains a JC instance, through which the misbehavior- 
Judge ABI of the JC can be run by the ACC. Based on the above fields and variables, we designed the access- 
Control ABI as in Algorithm 1, which receives the inputs of resource, action and time (i.e., when the request is 


sent), and returns the access result and penalty. 
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Algorithm 1 accessControl ABI 


0: | resource, action, time 
0: | result, penalty Require: policyCheck + false, behaviorCheck <— true, penalty <— 0, JC instance judge, policy list policies, timeofUnblock of resource. 
1: | if This request is from the subject then 
2 p  policies{resource)[action]. 
3: if timeofUnblock < time then 
4: if timeofUnblock > 0 then 
5: p-NoFR <— 0,p.ToLR + 0, timeofUnblock — 0. 
6: end if 
7: if p.policy = allow” then 
8: policyCheck + true. 
9: else 
10: policyCheck + false. 
11: end if 
12: if time — p.ToLR < p.minInterval then 
13: p.NoFR <— p.NoFR +1. 
14: ifp.NoFR > p.threshold then 
15: Detect a misbehavior msb. 
16: behaviorCheck <— false. 
17: penalty — judge.misbehaviorJudge(subject, msb). 
18: timeofUnblock <— time + penalty. 
19: Push msb into the misbehavior list of resource. 
20: end if 
21: else 
22: p.NoFR <— 0. 
23: end if 
24: end if 
25: p.ToLR < time. 
26: | endif 
27: | result + policyCheck and behaviorCheck. 
28: | Trigger event returnResult(result, penalty). 


The static validation is from Line 7 to Line 11 and the dynamic validation is from Line 12 to Line 23. The 
event returnResult(result, penalty) in Line 28 is used to return the access result and penalty to both the sub- 
jects and objects. For the detailed implementation of the ACC, please refer to [39]. 


V-B2 RC 


The key issue in the implementation of the RC is to construct the loopup table as shown in Table III. Like the 
construction of policy list for the ACC, we used a struct to store the information of each method and applied a 
mapping from the field of MethodName to this struct to construct the loopup table. 


V-B3 JC 


In the implementation of the JC, we used a dynamic array to store the misbehavior records of a subject. We 
considered a simple misbehavior judging method, which treats all potential misbehavior received from the 
ACC as misbehavior. When receiving a misbehavior report of a subject from the ACC, the misbehaviorReport 
ABI pushes the misbehavior into the misbehavior record array of the subject and then uses the following 
function to determine the corresponding penalty: 


penalty = (base)! / interval] m 


where @ is the number of misbehavior that the subject has exhibited (i.e., the length of the misbehavior 
record array of the subject), and base and interval are parameters that determine how the penalty changes 
with @. Notice that base and interval are initialized when the JC is deployed. 


V-B4 JavaScripts at the subject and object 


https://ardiv.labs.arxiv.org/html/1802.04410 15/24 


11/7/23, 10:01 AM [1802.04410] Smart Contract-Based Access Control for the Internet of Things 


The access control in this study is implemented based on the case in Fig. 5a, where the ACC is called by the 
subject and the result is returned to both sides. To implement the access control, we created two JavaScripts 
(one at the subject and the other at the object) using the web3.js to interact with the JC and ACC. As shown in 
Algorithm 2, the JavaScript at the subject side first retrieves the address addr and ABI abi of the ACC from the 
RC (Line 1 - Line 3) and then sends a transaction that contains the access request information (resource, ac- 
tion, time) to run the accessControl ABI of the ACC for access control (Line 4 - Line 5). Finally, the JavaScript 


watches the event returnResultQ returned from the accessControl ABI to retrieve the access result (Line 6 - 
Line 11). 


Algorithm 2 Access Request JavaScript 


resource, action, time 
result, penalty 
Create a RC instance register. 
Specify the access control method name method. 
(addr, abi) — register. getContract(method). 
Create an ACC instance acc with addr, abi. 
Send a transaction containing parameters (resource, action, time) to the accessControl ABI of acc. 
while ture do 
if Event returnResult() is captured then 
(result, penalty) — returnResult(). 
break. 
end if 
end while 
return result, penalty 


SO DOESN, ta OE SS 


ee 
aS 


XY 


The JavaScript at the object side is illustrated in Algorithm 3), which uses the same statements (Line 1 - Line 


3) to retrieve the address and ABI of the ACC from the RC and infinitely watches the returnResultQ events 
from the ACC to know who wants to access which resource at what time, and what the corresponding result 


and penalty are (Line 4 - Line 10). 


Algorithm 3 Access Monitor JavaScript 


Create a RC instance register. 
Specify the access control method name method. 
(addr, abi) — register. getContract(method). 
Create an ACC instance acc with addr, abi. 
while ture do 
if Event returnResult() is captured then 
(result, penalty) — returnResult(). 
Display result, penalty. 
end if 
end while 


SO OO A Oy AN 8 Ri a RO! ake 


S 


V-C Experiments 


Our source code for the ACC, JC, RC and JavaScripts of the case study is now available at [39]. Based on the 
code, the hardware and software, we conducted experiments to show the feasibility of the framework for ac- 
cess control. We added a policy to the ACC with minInterval set to 100 seconds and threshold set to 2. We also 
set the base and interval in the JC to 2 and 3, respectively. 


https://ardiv.labs.arxiv.org/html/1802.04410 16/24 


11/7/23, 10:01 AM [1802.04410] Smart Contract-Based Access Control for the Internet of Things 


tx) pi@raspberrypi: ~/EthProjects/wWeb3JS 


Contract: OxcboOfd2ff3f2eccd254f72d822aaca8fca2851a45 
Block Number: 42998 
Tx Hash: 0xd979672f4cf17b916da8fa860cb816a5287f368c018197ece9531bbeeO4dbd21 
Block Hash: 0x492491f7a58b501602dc3fa6108a085b8bf2e7213debb9497abb8S5af79d1abbd 
Subject: 0x0d1f8a489b1312689f11f7fe79dfc3b61ffa4160 
Time: 1517391448 

Access authorized! 

true 


Contract: Oxcbofd2ff3f2eccd254f72d822aaca8fca2851a45 

Block Number: 43001 

Tx Hash: 0x7ae4562ba915af4a86dbi8eef6cSa4acf30b40fc83c69cde67c93f1a869614d1 
Block Hash: 0xcd9c7b06394d8e912aa1Cc24e21e817902cbf397052d08eb3232241ee7fc42be3 
Subject: 0x0d1f8a489b1312689f11f7fe79dfc3b61f fa4160 

Time: 1517391480 

Message: Access authorized! 

Result: true 


Contract: OxcbOfd2ff3f2eccd254f72d822aaca8fca2851a45 
Block Number: 43004 
Tx Hash: 0xd3136f97ece2S5ac9a2a2fedbfb9d00d8b825fccbad7a74eb96caed688f411c19 
Block Hash: OxOebbc9ceaf2537e081b5ed8cc4a77d6e447582c1fbO0558bf0acaa8s679aa3Cc2a 
Subject: 0x0d1f8a489b1312689f11f7fe79dfc3b61f fa4160 
Time: 1517391501 
Misbehavior detected! 
false 
Requests are blocked for 1 minutes! 


(a) Results at the object. 
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@ yuanyuzhang — pi@raspberrypi: ~/EthProjects/Web3JS — ssh pi@163.221.216.... 


Send access request?(y/n)y 

Contract: @xcb@fd2ff3f2eccd254F72d822aaca8Fca2851a45 

Block Number: 42998 

Tx Hash: @xd979672f4cf17b916da8fa860cb816a5287 F368c018197ece9531bbeeG@4dbd21 
Block Hash: @x492491f7a58b501602dc3fa6108a085b8bf2e7213debb9497abb85af79d1abbd 
Time: 1517391448 

Message: Access authorized! 

Result: true 


Send access request?(y/n)y 

Contract: @xcb@fd2ff3f2eccd254f72d822aaca8Fcoa2851a45 

Block Number: 43001 

Tx Hash: @x7ae4562ba915af4a86db1i8eefé6ch5a4acf30b40fc83c69cde67c93F1a869614d1 
Block Hash: @xcd9c7b@6394d8e912aa1c24e21€817902cbf397052d88eb3232241ee7Fc42be3 
Time: 1517391480 Figure 8: Access results after misbehavior occurring once. 


Message: Access authorized! 
Result: true 


AA AUER FRIERE AM ayed 
reenact: EA E A 


nenact: axeberazt tarzeccazyat a JavaScripts af the object (Fig. 8a) and subject (Fig. 8b), when 


irst tine. Fig. 9 m. 10 show the access results, when the 
syhjegh emhibiteddhe atip pekavigs don three dupep gndousbaress cespratinelve Hrer RNA the request of 


Result: false 
Requests are blocked for 1 minutes! 


pi@raspberrypi: ~/EthProjects/Web3JS 


Contract: OxcbOfd2ff3f2eccd254f72d822aaca8fca2851a45 

Block Number: 43019 

Tx Hash: 0xb11fe604e212b4f3e0dc42ba94c1ad819d7dae759623b58e4ab8833322e1b5e1 
Block Hash: 0x600139ab20c3daf9b88feOf 28f73e72d4325994c1186ea18F0927a975743bbc0 
Subject: 0x0d1f8a489b1312689f11f7fe79dfc3b61ffa4160 

Time: 1517392205 

Message: Misbehavior detected! 

Result: false 

Requests are blocked for 2 minutes! 


Contract: OxcboOfd2ff3f2eccd254f72d822aaca8fca2851a45 
Block Number: 43022 
Tx Hash: 0x8282db9ae8b30387fa3e5ef9d335a5d676d31536b370f9c75681887054dd6999 
Block Hash: Ox97c2acc4bcOfileaeb74e75017baedc8b90bb7b59d4f f59f fa77735b65c080612 
©x0d1f8a489b1312689f11f 7fe79dfc3b61f fa4160 
1517392241 
Requests are blocked! 
false 


(a) Results at the object. 
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C yuanyuzhang — pi@raspberrypi: ~/EthProjects/Web3JS — ssh pi@163.221.216.... 


Send access request?(y/n)y | 
Contract: OxcbOfd2ff3f2eccd254F72d822aaca8Fcoa2851a45 

Block Number: 43019 

Tx Hash: @0xb11fe604e212b4f3e0dc42ba94c1ad819d7dae759623b58e4ab8833322e1b5e1 

Block Hash: 0x600139ab20c3daf9b88feðf28f73e72d4325994c1186ea18f0927a975743bbc0 
Time: 1517392205 

Message: Misbehavior detected! 

Result: false 

Requests are blocked for 2 minutes! 


Send access request?(y/n)y 

Contract: OxcbOfd2ff3f2eccd254F72d822aaca8Ffcoa2851a45 

Block Number: 43022 | 
Tx Hash: @x8282db9ae8b30387fa3e5ef9d335a5d676d31536b378F9c75681887054dd6999 

Block Hash: @x97c2acc4bcOfleaeb74e75017baedc8b9Obb7b59d4FF59 fF fa77735b65c080612 
Time: 1517392241 

Message: Requests are blocked! 

Result: false 


(b) Results at the subject. 


Figure 9: Access results after misbehavior occurring for three times. 


pi@raspberrypi: ~/EthProjects/Web3JS 


ontract: OxcbOfd2ff3f2eccd254f72d822aaca8fca2851a45 
Block Number: 43123 
x Hash: 0x31564a8518ca665526fced6f5c04e10069a25581d9cS5bf8bcc3b5fbdaf559ad2 
Block Hash: 0x6f53454d4975712f6d77ca2fb35e9f f6cd5cce278f51431640c3280a102ebbf9 
0x0d1f8a489b1312689f11f7fe79dfc3b61f fa4160 
1517394129 
: Access authorized! 
true 


OxcbOfd2ff3f2eccd254f72d822aaca8fca2851a45 
Block Number: 43126 
Tx Hash: 0x79a797522ec26ba483ed796a8b693a39e04Ff 589f938a6a353970690851d3967e 
Block Hash: 0x469f716e9fe9b83bdd537c51974a301d3e39e0cd6d4dc37d3b0d71c75f11f69a 
ubject: 0x0d1f8a489b1312689f11f7fe79dfc3b61f fa4160 
ime: 1517394162 
essage: Misbehavior detected! 
Result: false 
Requests are blocked for 4 minutes! 


(a) Results at the object. 
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@® © @ “© yuanyuzhang — pi@raspberrypi: ~/EthProjects/Web3JS — ssh pi@163.221.216.... 


Send access request?(y/n)y 

Contract: @xcb@fd2ff3f2eccd254f72d822aaca8fca2851a45 

Block Number: 43123 

Tx Hash: @x31564a8518ca665526fced6f5c04e10069a25581d9c5bf8bcc3b5fbdaf559ad2 
Block Hash: @x6f53454d4975712f6d77ca2fb35e9f fécd5cce278f51431640c3280a102ebbf9 
Time: 1517394129 

Message: Access authorized! 

Result: true 


Send access request?(y/n)y 

Contract: O@xcb@fd2ff3f2eccd254F72d822aaca8fcoa2851a45 

Block Number: 43126 

Tx Hash: @x79a797522ec26ba483ed796a8b693a39e04 F589 F938a6a353970690851d3967e 
Block Hash: 0x469f716e9fe9b83bdd537c51974a301d3e39e8cd6d4dc37d3b0d71c75f11f69a 
Time: 1517394162 

Message: Misbehavior detected! 

Result: false 

Requests are blocked for 4 minutes! 


Send access request?(y/n)ff 


(b) Results at the subject. 


Figure 10: Access results after misbehavior occurring for six times. 


VI CONCLUSIONS 


This paper investigated the access control issue in the IoT, for which we proposed a smart contract-based 
framework to implement distributed and trustworthy access control. The framework includes multiple ac- 
cess control contracts (ACCs) for access control between multiple subject-object pairs in the system, one 
judge contract (JC) for judging the misbehavior of the subjects during the access control, and one register 
contract (RC) for managing the ACCs and JC. A case study was also provided for the access control in a IoT 
system with one desktop computer, one laptop and two Raspberry Pi single-board computers. The case study 
demonstrated the feasibility of the proposed framework in achieving distributed and trustworthy access con- 
trol for the IoT. 
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